IBIS Macromodel Task Group

Meeting date: 23 July 2024

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Aurora System:              * Dian Yang
                              Raj Raghuram
Cadence Design Systems:     * Ambrish Varma
                              Jared James
Dassault Systemes:            Longfei Bai
Google:                       Hanfeng Wang
                              GaWon Kim
Intel:                      * Michael Mirmak
                            * Kinger Cai
                              Chi-te Chen
                              Liwei Zhao
                              Alaeddin Aydiner
                              Sai Zhou
Keysight Technologies:      * Fangyi Rao
                              Majid Ahadi Dolatsara
                              Stephen Slater
                              Ming Yan
                              Rui Yang
Marvell:                      Steve Parker
Mathworks (SiSoft):         * Walter Katz
                              Graham Kus
Micron Technology:            Justin Butterfield
Missouri S&T:               * Chulsoon Hwang
                            * Yifan Ding
                              Zhiping Yang
Rivos:                        Yansheng Wang
SAE ITC:                      Michael McNair
Siemens EDA (Mentor):       * Arpad Muranyi
                            * Randy Wolff
Signal Edge Solutions       * Benjamin Dannan
Teraspeed Labs:               [Bob Ross]
Zuken USA:                  * Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

Yifan: Prepare a draft of BIRD220.1 and send it to the ATM list.
       - Done.
  
-------------
Review of ARs:

- None.
            
--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the July 16th
meeting.  Michael moved to approve the minutes.  Lance seconded the motion.
There were no objections.

--------------
New Discussion:

BIRD220 update:
Yifan reviewed a presentation on a work-in-progress update to the BIRD220.1
draft she had sent to ATM.  The new version incorporated feedback received from
Randy and others.

BIRD220 introduced a [Pre-driver PSIJ Sensitivity] keyword with two sub-params
providing single values for the rising and falling edges.  BIRD220.1 proposes
[PreDrv PSIJS Rising_edge] and [PreDrv PSIJS Falling_edge], both of which are
tables in order to incorporate non-linearities.  She reviewed the changes in the
algorithm and the updated and simplified extraction process relative to BIRD220.

One question received in response to the draft BIRD220.1 was whether we should
scope the new keywords under the [Rising|Falling Waveform]s instead of [Model].
Yifan said we could discuss this possibility.  However, she expressed concerns
about this idea.  She noted that rising and falling waveforms are generated
under particular load conditions, and the model developer might not necessarily
use the same load conditions when extracting the jitter sensitivity information.
Arpad said that it is typical to extract 4 waveforms for an I/O buffer [Model]
(2 rising and 2 falling), and he asked whether these PSIJ tables would be the
same under all load conditions or need to be different for different waveforms.
Yifan said the pre-driver sensitivity information should be identical for
different load conditions, and the various loads are connected to the final
driver and therefore would not affect the pre-driver behavior.  Fangyi agreed
and said the pre-driver sensitivity tables can't be dependent upon the load
conditions, otherwise this whole approach doesn't work.

Kinger said he thought the rising and falling waveforms in IBIS are for the
final stage.  He said they wouldn't care about the pre-driver stage.  Arpad
agreed that the rising and falling waveforms are largely about characterizing
the output stage, but he noted that the way the driver turns on depends upon the
way the pre-driver changes the gate voltage on the output transistor.  So, there
are pre-driver effects included.

Randy noted that several years ago he had presented some data in ATM for a DDR5
device.  He recalled that if you try to characterize PSIJ to different test
loads, the data shifts around.  He said we're trying to characterize the pre-
driver delay and how it might be changing.  If you don't have access to the pre-
driver delay waveform, for example by probing at the gate of the driver, then
you have to try and infer it from measurements of the final driver delay.  That
is where it can get messy.  You could show what PSIJ is for four different
waveforms and then try to infer what the pre-driver is doing.  But ideally you
want to characterize the pre-driver waveform itself.  Arpad asked whether
different values for V_fixture and R_fixture would affect the values in these
new keywords.  Randy said we could review his earlier data, but you'd have to
try to infer what's going on in the pre-driver stage.

Yifan drew a simple inverter chain pre-driver example connected to the output
stage.  She said the load is connected to the output stage, and the pre-driver
delay won't change based on the output's load.  So, we should only need a
single table for the pre-driver portion (one each for rising and falling).
Fangyi said this is expected behavior.  The pre-driver ends at the gate.  The
gate voltage is decoupled from the load.  Arpad said it's decoupled to some
extent, but we do have the Miller capacitance between the drain and the gate.
Randy observed that IBIS has always tried to provide data that could have been
measured.  He said this is an example of something you can't really measure.  He
said this is more like an AMI black box concept where you're providing data
about something that's going on inside the device.  This is great for a
simulation-based model, but it's tough to come up with a measurement-based
extraction.

Arpad said we typically have 4 waveforms in order to characterize how the pre-
driver turns the pullup and pulldown transistors on or off.  He said this
proposal contains separate tables for rising and falling, but he asked the group
to consider whether we might need two tables for rising and two tables for
falling.  He noted that the rising waveform when you have a load of 50 Ohms to
ground is governed by the pullup turning on.  However, the rising waveform when
you have 50 Ohms to Vcc is governed by the pulldown turning off.  He said these
were two different things, and if the pre-driver delay data would be different
for these two conditions, then it would make sense to put that data under the
rising and falling waveform keywords.  Fangyi said that if we could do that,
then we could account for all the jitter happening in the pre-driver and the
driver.  Then we could model what Randy observed.  He said it would be a
superset of this proposal, and we would have to go back and review the equations
and figure out how to calculate a delay value at a certain load condition.  He
said that in a normal simulation scenario the model is not going to know the
instantaneous load condition.  We would have to rethink the formulation.

Kinger said the pre-driver might well be operating at a different voltage than
the final stage.  So, we should not put pre-driver jitter sensitivity data
inside the waveform data for the final stage.  Yifan agreed and said it is noted
as a limitation of this proposal that the pre-driver and final stage must share
the same power net.  Arpad agreed that IBIS itself currently doesn't support
independent supplies for pre-driver and output stages.  He said it's currently a
fundamental limitation of IBIS.  Yifan said we would need a different BIRD if we
wanted to introduce support for different power nets for the pre-driver and
final stages.  Randy said that would also affect ISSO tables and other model
keywords.

Yifan proposed a case study with the load conditions for the 4 rising/falling
waveforms to see if the pre-driver jitter sensitivity data is affected by load
or not.

Yifan noted another suggestion from Randy.  Randy had suggested that we might
allow the model maker to provide the jitter curve directly.  The tool can then
compute the derivative (jitter sensitivity in s/V) instead of asking the model
maker to provide jitter sensitivity in the table.  The keywords would be renamed
to remove the "sensitivity".

Yifan also noted that although the derivation of the jitter sensitivity is done
with DC voltage values, it is applicable to AC power noise as well.

Yifan said concern had been raised about the possibility of the time averaged
VCC noise and the jitter sensitivity value resulting in a negative time shift
delta t in the formulation:
    Ku(t) = Kuo(t + delta t)
She said a positive or negative time shift is not a problem as the reference
Ku0(t) curve has data at "all times".  Fangyi agreed, he said this is not a true
"time", it's a fictitious time that is more of a parameter of the K(t) table.
Fangyi also noted that in the function representing the propagation delay
(delta t), we should make it clear that "DC Jitter Sensitivity" is now a look up
table value and not a constant.

Yifan said she would send out a new BIRD220.1_draft2.  She said she would
perform the case study to determine whether pre-driver jitter sensitivity is
affected by output load.

[Ramp] and Ts4file:
Michael shared a presentation detailing a possible ambiguity in the treatment of
Ts4file, particularly by the ibischk parser.  He reviewed the Ts4file Tx and Rx
analog circuits (Figures 46 and 47, IBIS 7.2).  He said that Arpad had explained
that the Tx_R valued resistors are there to reduce reflections from the ideal
stimulus sent to ports 1 and 3 of the Ts4file.  Randy said Tx_R could represent
the linearized drive impedance.  The model maker could separate that from the
.s4p file, or they could include that in the .s4p and set Tx_R to zero.  Fangyi
agreed that the model maker can include what they want in the Ts4file, and Tx_R
is there to give the model maker flexibility.  Fangyi said that Tx_R and Rx_R
were introduced because historically many people mistakenly thought that when
they got an S-parameter file they should terminate it with the reference
impedance.  Explicitly introducing Tx_R and Rx_R made it clear what values
the model maker wanted the tool to use.

Michael said the problem is that the ideal stimulus to the Ts4file is not well
understood with respect to [Ramp] and the I-V and V-t tables in the IBIS file.
For example, does the dV/dt value in the [Ramp] correspond to the ideal stimulus
to the .s4p or the output of the .s4p?

Ambrish asked whether Michael was looking for clarification on how [Ramp]
interacts with Ts4file.  He said Ts4file is an alternative analog buffer model
for AMI only.  He noted the first sentence in 10.10, IBIS 7.2:
  This section discusses an alternative analog buffer modeling technique,
  specifically designed for AMI applications.  
Fangyi then noted the final paragraph in 10.10.2, IBIS 7.2:
  By definition, the placement of the Ts4file information within .ami files
  makes the Ts4file data exclusively limited to AMI applications.  If the same
  electrical behavior is desired for non-AMI applications of the same IBIS model
  (the one referencing the Algorithmic Model) the model maker can optionally
  provide an equivalent description using the [External Model] keyword. 
  However, the latter is not needed if the model is intended for AMI
  applications only.

Ambrish said the Ts4file is explicitly intended to replace the contents of the
traditional IBIS analog model ([Ramp], I/V curves, etc.), and the parser should
not be checking those elements in a model containing a Ts4file.  The same is
true if [External Model] is used.  Michael said that we had not given that
guidance to the parser developer.  He said that if the caution level checking is
enabled in the parser, which he strongly recommended all model makers do, then
the parser issues cautions about the [Ramp] data even in AMI models using
Ts4file.  He said if the intent is that the traditional analog model elements
be ignored when Ts4file is used, then that solves his problem.  We need to
submit a parser BUG and have the parser stop checking analog elements.  Ambrish
said that should be the case when [External Model] is used as well.  Michael
said he wasn't sure if the parser was checking traditional analog keywords in
that case too.  Randy agreed that we can update the parser behavior.

- Ambrish: Motion to adjourn.
- Michael: Second.
- Arpad: Thank you all for joining.

New ARs:

Yifan: Prepare draft2 of BIRD220.1 and send it to the ATM list.

-------------
Next meeting: 30 July 2024 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
